前言

滿多預計要討論的其他Task最後都沒有實作到，居然意外變成是純粹以Classification為例的深度學習實作範例了！在此作為系列篇的最後一篇，打算分享一下這段時間作Deep Learning的一些心得及想法。

勿過度沉迷於技術

其實這個小標同時也是在告誡自己，大家可以看到在[Day21]當中，其實我們的AUROC已經達到0.731，距離我們最後的0.772其實也僅是提升了0.041。但這0.041我們卻使用了大約構築第一次實驗結果的好幾倍時間來進行實驗才得到。

先分享一個非常寫實、也讓人又氣又好笑的深度學習迷因（出處）：

身為一個理工宅出身的人，我個人認為深度學習的技術是迷人的。有趣的數學性質、各種實驗的曲線、以及加入各種調整以後的改善結果，那種「我再試一些超參數是不是就會變好」的心態，真的很可怕！我覺得裡面應該已經有一些多巴胺陷阱的成分。不過總歸來說，一切仍需要適度而止。尤其是不要陷入把Test Set當作另外一個Validation Set來不斷優化的無底洞陷阱中，一來是能改善的幅度有限，二來則是所見也可能並非是真正的改善。

那麼，這些操作，究竟值不值得呢？我的回答是：要看目標。

回歸初心，專注目標

目標的話，個人的經驗目前可以粗分成兩種：

• 研究型：通常研究型的問題，大多的情況比較會是追求某一個單點的突破。例如更加符合domain的損失函數、更加精良或高效的網路框架、或是更加高效的迭代方式諸如此類。通常是建議需要先釐清自己的研究目標，在單個點上作討論，不然東混西混的情況下，實驗與問題往往會無法收斂。
  • 例如：想證明A LOSS比B LOSS好，但卻花費大量經歷在那邊tune learning rate或是optimizer，卻也只好一些。殊不知很可能實際上A就是跟B差不多。
• 商業型：商業型的本質其實更加單純，說穿了就是錢。什麼模型（或模型的組合）在可用的時間底下，效益（很廣泛，可能是對公司的商業模式來說，而非只得是程式執行效率）能最好。能在考量到時間金錢成本的狀況下，要進行資源的配置。
  • 例如：一般而言，資源配置是PM的工作居多。但如果RD完全沒有意識到成本概念，只覺得PM根本不懂技術在亂搞，然後又剛好碰到PM本身技術底又不夠，只覺得RD不懂得捉大放小時，兩者的溝通根本是災難一場。
    • 懂成本的RD能以技術溝通出更有效的解法，懂技術的PM則更能說服RD引導出其能力的價值，本質是真正的合作。
  • 例如：如果目標是半年內要有產品的Prototype，其產品需要A B C三個模型，某A模型已經達到95%的準確率了。究竟要追求更高的A還是花時間去作B與C？我的建議仍是要評估。
    • 如果類似A模型的準確度在已知的文獻或人類表現極限差不多就是95%，且這個A對於最終服務的影響不致於大影響時，就不宜在投入過多成本。應該把成本優先完成B、C，打造雛形。
    • 如果A模型是產品的本身最主要的關鍵，例如提升1%可以為公司本業多創造多少收益的情況下，就十分適合投入時間持續進行研發。（當然本身的可行性還是要評估，而不是永無止盡的研發下去）
    • 千萬要避免的狀況是B、C都還沒有個底，在有限的成本底下還把資源投入到已經差不多到極限的A上。

資料是一切的根本

深度學習或是機械學習，最重要的一點其實是後面共通的那兩個字「學習」（Learning）。向什麼學習？資料（DATA）。

由於很多技術實施者大多都是從被整理好的公開資料集開始進行學習，因此這一點其實很常被遺忘。整個系列的MedMNIST其實就屬於這類已經經過大量資料清理、驗證的標準資料集，而且又有模型預測的標準可供參考，供學習者能專注在演算法的學習與開發上。

但大多的AI專案做不出來，其實問題不外乎都是出現在根本的資料問題上，而這個問題又可以分成幾個層次討論，我這邊依嚴重度高到低依序討論：

1. 實行根據不清楚的AI任務，例如，想做某種標籤的預測，但這個標籤，實際連給標籤的人都沒有定義上的共識就進入讓模型學習的流程，可想而知，連人都搞不懂，模型也很難懂。基本上我個人會稱謂這種是奇蹟型的開發專案。
2. 驗收標準不清楚的AI任務，例如，想做某個疾病或是某個產線上瑕疵發生的預測或自動判斷，經過開發人員的努力可能已經有85%的成效了（可能是AUC、準確度之類的某個驗收指標），但團隊（包含老闆）沒有足夠的共識，只會一昧的追求表現更好，但殊不知模型的表現可能已經接近人類專家的表現能力，不太可能有繼續提高的機會。
3. 定義清楚，但資料不足卻不自知的AI任務。例如，某案子目標與驗收標準都很明確，但團隊沉溺於用諸多技術在有限資料上的改進，殊不知根本問題其實只是資料樣本不夠大，不足以應付宏觀世界導致。這類屬於最輕的，利用適合的成本增加資料量即可！

以上大概是綜觀個人在職場上幾年的一些小心得。

在系列文的最後，感謝細心讀到最後一篇的觀眾們，如果有什麼想法也都歡迎在討論串提出來互相討論，或是也可以mail到我個人信箱進行交流。

系列文的Github連結

本系列文的實作一律都放在 https://github.com/SraRod/iThome2022
有興趣的讀者可以直接上去抓下來實作，有什麼issue也都可以直接在上面提出來。在此感謝你的閱讀！